Contextual policy weighting for permissions searching

ABSTRACT

An indication to perform a permissions policy search may be received by an interface of an identity management service. A context may be determined associated with the permissions policy search. A plurality of weights for a plurality of permissions policies may be calculated based on the context. An order for display of the plurality of permissions policies may be determined based on the plurality of weights. The plurality of permissions policies may be presented, in a display area within the interface, in the order that is based on the plurality of weights. A selection of a first permissions policy from the plurality of permissions policies may be received by the interface. The first permissions policy may be attached to a first identity based at least in part on the selection of the first permissions policy.

BACKGROUND

Identity management services may allow customers to control and manageaccess to resources by creating identities (e.g., users, groups, roles,etc.) and defining permissions for the identities. In some examples,permissions for an identity may be defined by attaching policies to anidentity. Some example policy names may include a name of a service anda corresponding permission (e.g., AAServiceReadOnly, BBServiceFullAcess,etc.), while some other example policy names may include a job function(e.g., DataScientist, Billing, etc.). An identity management service mayprovide an interface, such as a web console interface, that allows acustomer to select a given identity and to search for permissions toattach to the given identity, for example by entering search terms intoa text entry field. In some examples, an available policy corpus mayinclude both vendor-managed policies as well as private customer-definedpolicies. In some examples, there may be large quantities of availablepolicies from which to search. For example, in some cases, a givenvendor may offer five-hundred or more managed policies, while largecustomers could have up to ten-thousand policies.

BRIEF DESCRIPTION OF DRAWINGS

The following detailed description may be better understood when read inconjunction with the appended drawings. For the purposes ofillustration, there are shown in the drawings example embodiments ofvarious aspects of the disclosure; however, the invention is not limitedto the specific methods and instrumentalities disclosed.

FIG. 1 is a diagram illustrating an example weighted policy searchsystem that may be used in accordance with the present disclosure.

FIG. 2 is a diagram illustrating a first example policy weighting basedon identity information that may be used in accordance with the presentdisclosure.

FIG. 3 is a diagram illustrating a second example policy weighting basedon existing attached policy information that may be used in accordancewith the present disclosure.

FIG. 4 is a diagram illustrating a third example policy weighting basedon related identities that may be used in accordance with the presentdisclosure.

FIG. 5 is a diagram illustrating a fourth example policy weighting basedon usage history that may be used in accordance with the presentdisclosure.

FIG. 6 is a diagram illustrating an example weighted policy searchsystem with result filtering that may be used in accordance with thepresent disclosure.

FIG. 7 is a diagram illustrating an example policy creation interfacewith inferred feature suggestions that may be used in accordance withthe present disclosure.

FIG. 8 is a flowchart illustrating an example weighted policy searchingprocess that may be used in accordance with the present disclosure.

FIG. 9 is a diagram illustrating an example system for transmitting andproviding data that may be used in accordance with the presentdisclosure.

FIG. 10 is a diagram illustrating an example computing system that maybe used in accordance with the present disclosure.

DETAILED DESCRIPTION

Techniques for contextual policy weighting for permissions searching aredescribed herein. The described techniques may be employed by anidentity management service, which may allow customers to control andmanage access to resources by creating identities (e.g., users, groups,roles, etc.) and defining permissions for the identities. The identitymanagement service may provide an interface, such as a web consoleinterface, that allows a user, such as an administrator, to select agiven identity and to search for permissions to attach to the givenidentity. In one specific example, a user may select a given identityfor which to define permissions by navigating to an identity page forthe given identity within the web console. The user may then select anattach policies button, or other control, on the identity page in orderto search for policies to attach to the identity. Selection of thiscontrol may cause a search page to be displayed to the user. In someexamples, the search page may include a text entry field as well as adisplay area that includes a scrollable list of selectable policies. Inone specific example, a policy may be selected by checking a respectivecheckbox or other selection control, such as may be adjacent to thepolicy in the scrollable policy list.

As described above, in some cases, there may be large quantities ofavailable policies from which to search to find a selected policy. Insome conventional techniques, query terms, which are entered by a user,such as via the text entry field within the search page, are used tofilter the corpus of available policies. In one specific example, thefiltering is performed on a case-insensitive substring match of theentered query terms. For example, policy names that include acase-insensitive substring match of a query substring are filtered-insuch that they are included in the filtered policies, while policy namesthat don't include a substring match re filtered out and dropped. Theresulting filtered policies are then displayed in the scrollable policylist in lexicographical (e.g., alphabetical/numerical) order.

One problem with these and other similar conventional techniques is thatthe resulting set of filtered policy names, which are determined basedon query term matching, may still be quite large, thereby potentiallyforcing a user to scroll through large quantities of undesired policiesto find a selected policy name. For example, if a user types the queryterms “read only” into a text entry field, a conventional search pagecould potentially return a list that includes all policies that provideread-only access to any service offered by, or affiliated with, thevendor. For major vendors that provide large quantities of affiliatedservices, this may be a long list that includes many read-only policies.Moreover, because naming conventions and formats may differ betweendifferent policies and services, a user may be unsure of thelexicographical position of a policy name within the ordered list.Specifically, many policy names may indicate services by placing a nameof a parent vendor that provides the service at start of the service'sname. This may cause many policy names to start with the same letter(e.g., the first letter of the parent vendor's name) and may also causethe policy name to appear in a different lexicographical order than theuser was expecting, thereby causing confusion and frustration. Yetanother problem with conventional techniques is that policies that grantfull administrator access, which may often be named AdministratorAccess(or similar), may commonly appear at the top of the policy listing, forexample because the word “administrator” may often be one of the firstwords listed when policies are placed in alphabetical order. This highlisting of the administrator access policy, in combination with thedifficulty of finding a selected policy name, may cause users to grantadministrator access to policies for which administrator access is notactually required, thereby resulting in potential misappropriation ofpermissions and other potential security and privacy concerns.

To address these and other concerns, the techniques described herein mayallow policies to be weighted (e.g., ranked) based on relevant contextinformation. The weighted policies may then be displayed in an orderbased on their respective weights. A policy's position in an orderedlist may be determined based on its respective weight (e.g., rank), forexample such that higher weighted policies are displayed with a higherpriority (e.g., higher up in the list), while lower weighted policiesare displayed with a lower priority (e.g., further down in the list). Insome examples, the context information that is used to weight thepolicies may include identity information (e.g., identity name, identityage, etc.), existing attached policy information, related identities(e.g., other identities within the same account), usage history, consolebrowsing history, query terms, and other information. Thus, thetechniques described herein may allow search results to be providedbased on information other than merely manually-entered query terms andmay also allow search results to be weighted based on context.

In some examples, when a user selects a given identity to which toattach a policy (e.g., by navigating to a respective page for the entityin the console and clicking an attach policy button), information aboutthe identity may be used to weight the list of policies. As a specificexample, many identity names may often include a name of a service withwhich the identity is associated. For example, an identity associatedwith a service called XXService might be named My-XXService-Role, whileanother identity associated with a service called YYService might benamed My-YYService-Role. Some conventional searches of policy namesmight yield exactly the same results in exactly the same order for bothMy-XXService-Role and My-YYService-Role, even though these roles areclearly associated with different respective services. By contrast, thetechniques described herein may allow policies associated with XXServiceto appear at the top of the policy listing for My-XXService-Role, whilealso allowing policies associated with YYService to appear at the top ofthe policy listing for My-YYService-Role.

In addition or as an alternative to identity information, other forms ofcontext information may also be used to weight the policies. Forexample, in some cases, existing policy information may be used, whichmay include information regarding existing policies already attached tothe identity and/or to related identities (e.g., identities within thesame account). For example, in some cases, a weighting component maydetermine that AAService is frequently used in combination with anotherservice named XXService. In this example, a weighting component mayexamine the existing policies that have already been attached to anidentity named First-Example-Role and determine that a policy namedAAServiceFullAccess has already been attached to First-Example-Role.Thus, because the weighting component knows that the First-Example-Rolehas already been granted access to AAservice, and because the weightingcomponent also knows that AAService is frequently used in combinationwith XXService, the weighting component may choose to assign higherweights to policies associated with XXService than to other policies. Inanother example, a weighting component may weight policies for theFirst-Example-Role identity by looking at other related identities thathave been created within a same account as First-Example-Role. In thisexample, the weighting component may determine that each of these otherrelated identities has been assigned a policy named XXServiceFullAccess.Thus, because the weighting component knows that these relatedidentities have already been assigned the XXServiceFullAccess policy,the weighting component may choose to assign a higher weight to theXXServiceFullAccess policy than to other policies.

Additionally, in some examples, the weighting of policy names may beperformed based at least in part on a usage history of the identity. Forexample, a weighting component may weight policies for theFirst-Example-Role identity by looking at the identity's usage history,such as to determine services that have been frequently and/or recentlyused by the identity. In this example, the weighting component maydetermine that First-Example-Role has frequently and/or recentlyaccessed AAService. As described above, the weighting component may alsoknow that AAService is frequently used in combination with XXService.Thus, because the weighting component knows that First-Example-Role hasfrequently and/or recently accessed AAservice, and because the weightingcomponent also knows that AAService is frequently used in combinationwith XXService, the weighting component may choose to assign higherweights to policies associated with XXService than to other policies.

FIG. 1 is a diagram illustrating an example weighted policy searchsystem that may be used in accordance with the present disclosure. Asshown, an identity management service 150 is operated by a computingservices vendor 149. The identity management service 150 is a servicethat allows customers to control and manage access to resources bycreating identities (e.g., users, groups, roles, etc.) and definingpermissions for the identities. In the example of FIG. 1 , the identitymanagement service 150 provides an interface 151, such as a web console.The interface 151 includes a policy search page 100, which allows a userto search for permissions to attach to a given identity. In someexamples, a user, such as an administrator, may select a given identityfor which to define permissions by navigating to an identity page (notshown in FIG. 1 ) for the given identity within the web console. Theuser may then select an attach policies button, or other control, on theidentity page in order to search for policies to attach to the identity.Selection of this control may cause policy search page 100 to bedisplayed to the user. In other examples, the user could navigate firstto policy search page 100 (without previously selecting an identity) toselect a policy, and the user could then subsequently use the interface151 to select one or more identities to which to attach the selectedpolicy.

As shown in FIG. 1 , the policy search page 100 includes a text entryfield 111, a display area 112, a select policy button 113, and a createpolicy button 114. In the example of FIG. 1 , the text entry field 111is blank, meaning that the user has not yet typed any query terms intothe text entry field. The display area 112 includes a scrollable list ofselectable policies. In one specific example, a policy may be selectedby checking a respective checkbox 115, which in this example isdisplayed to the left of each policy in the scrollable policy list. Inthe example of FIG. 1 , the user has selected the XXServiceReadOnlypolicy by checking the checkbox 115 to the left of the XXServiceReadOnlypolicy. The user may then click the select policy button 113 to causethe XXServiceReadOnly policy to be attached to an identity. In someexamples, multiple policies may be selected from the scrollable listwhen the user clicks the select policy button 113, and those multipleselected policies may then be attached to the identity.

As shown in FIG. 1 , available policies 121 are permissions policiesthat are available to a customer that is interacting with the interface151. The available policies 121 may include both vendor-managedpolicies, such as may be managed by computing services vendor 149, aswell as private customer-defined policies. In some examples, there maybe large quantities of available policies from which to search. Forexample, in some cases, a given vendor may offer five-hundred or moremanaged policies, while large customers could have up to ten-thousandpolicies. The techniques described herein may allow available policies121 to be weighted (e.g., ranked) based on context information 126. Inthe example of FIG. 1 , a weighting component 125 employs the contextinformation 126 to form weighted policies 127 by assigning weights theavailable policies 121. The weighted policies 127 are then displayed indisplay area 112 based on their respective weights. The display area 112includes an ordered list of policies. A policy's position in the orderedlist may be determined based on its respective weight (e.g., rank), forexample such that higher weighted policies are displayed with a higherpriority (e.g., higher up in the list), while lower weighted policiesare displayed with a lower priority (e.g., further down in the list).For example, in FIG. 1 , XXServiceFullAccess is the highest weightedsearch result and is, therefore, shown at the top of the scrollablelist. XXServiceReadOnly is the second-highest weighted search result andis, therefore, shown second form the top of the scrollable list. Otherpolicies are weighted and displayed in the scrollable list accordingly.

In the example of FIG. 1 , the context information 126 includes identityinformation 201 (e.g., identity name, identity age, etc.), existingattached policy information 202, related identities 203 (e.g., otheridentities within the same account), usage history 204, interfacebrowsing history 205, and query terms 206. The context information 126may optionally include other information not shown in FIG. 1 .

In some examples, when a user selects a given identity to which toattach a policy (e.g., by navigating to a respective page for the entityin the console and clicking an attach policy button), information aboutthe identity may be used to weight the list of policies. Specifically,identity information 201 includes information about the identity forwhich a policy search is being conducted, such as the identity name,identity age, and the like. Referring now to FIG. 2 , an example isshown in which identity information 201 indicates that the name of anidentity for which a search is being conducted is My-XXService-Role. Inthe example of FIG. 2 , weighting component 125 receives the identityinformation 201 and determines that the identity name(My-XXService-Role) is clearly associated with the XXService. Based onthis determination, as shown in results 301, the weighting componentdecides that to assign higher weights to policies associated withXXService than to other policies. Accordingly, referring back to FIG. 1, it is seen that policies associated with XXService are the highestweighted policies and are therefore displayed at the top of the orderedlist in display area 112.

In addition or as an alternative to identity information 201, otherforms of context information 126 may also be used to weight thepolicies. Referring now to FIGS. 3-4 , examples are shown in whichpolicies are weighted based on existing attached policy information 202.In the example of FIG. 3 , a user has requested a policy search in orderto find and select a policy for attachment to an identity namedFirst-Example-Role, as indicated by identity information 201 of FIG. 3 .However, in this case, the identity name (First-Example-Role) is notclearly linked to any specific service. However, as shown in FIG. 3 ,the weighting component 125 receives existing attached policyinformation 202, which, in this example, indicates that a policy namedAAServiceFullAccess is already attached to First-Example-Role.Additionally, in the example of FIG. 3 , the weighting component 125also receives related service information 405, which indicates thatAAService is frequently used in combination with XXService. Thus, asindicated in results 401, because the weighting component 125 knows thatthe First-Example-Role has already been granted access to AAservice, andbecause the weighting component 125 also knows that AAService isfrequently used in combination with XXService, the weighting component125 chooses to assign higher weights to policies associated withXXService than to other policies.

In one specific example, AAService could be an object storage service,while XXService could be a data archiving service that is frequentlyused together with the object storage service. In some examples, bothAAService and XXSevice may be provided by the same vendor, such ascomputing services vendor 149. In some examples, computing servicesvendor 149 may provide several computing services and may analyze usagepatterns for the computing services to determine which of the computingservices are frequently used in combination with one another. In someexamples, usage data that shows service usage information (e.g., usagedates, times, durations, etc.) by customers of computing services vendor149 may be provided as input to a machine learning process. The machinelearning process may then analyze the usage data to determine whichservices are frequently used in combination with one another or areotherwise related to one another.

Referring now to FIG. 4 , another example is shown in which a user hasrequested a policy search in order to find and select a policy forattachment to the First-Example-Role identity, as indicated by identityinformation 201 of FIG. 4 . In this example, the weighting component 125receives related identity information 201, which indicates that anotheridentity, named Second-Example-Role, is included in the same customeraccount as First-Example-Role. The weighting component 125 may thereforedetermine that First-Example-Role and Second-Example-Role are relatedidentities. Additionally, existing attached policy information 202 ofFIG. 4 indicates that a policy named XXServiceFullAccess has beenattached to Second-Example-Role. Thus, as indicated in results 501,because the weighting component 125 knows that a policy associated withXXService has been assigned to Second-Example-Role (which is related toFirst-Example-Role), the weighting component 125 may, forFirst-Example-Role, choose to assign a higher weight to policiesassociated with XXService than to other policies.

Referring now to FIG. 5 , another example is shown in which theweighting of policy names is performed on based on a usage history of anidentity. In the example of FIG. 5 , a user has requested a policysearch in order to find and select a policy for attachment to theFirst-Example-Role identity, as indicated by identity information 201 ofFIG. 5 . In this example, the weighting component 125 receives usagehistory 204, which indicates that First-Example-Role has frequentlyand/or recently accessed AAService. Additionally, in the example of FIG.5 , the weighting component 125 also receives related serviceinformation 405, which indicates that AAService is frequently used incombination with XXService. Thus, as indicated in results 601, becausethe weighting component 125 knows that First-Example-Role has frequentlyand/or recently accessed to AAservice, and because the weightingcomponent 125 also knows that AAService is frequently used incombination with XXService, the weighting component 125 assigns higherweights to policies associated with XXService than to other policies.

Referring back to FIG. 1 , it is shown that the context information 126may also include interface browsing history 205. For example, in somecases, the weighting component 125 may track pages loaded, and otheractivities, performed within interface 151 (e.g., a web console) by auser and/or by multiple users within a same account. The weightingcomponent 125 may then use this interface browsing history 205 to assistin weighting of policies. For example, if the weighting component 125determined that a user has frequently and/or recently used the interface151 to load pages pertaining to YYService, then the weighting component125 may choose to assign a higher weight to policies associated withYYService than to other policies.

Referring back to FIG. 1 , it is shown that the user has not typed anyquery search terms into text entry field 111. Nevertheless, usingexamples such as those shown in FIGS. 2-5 and described above, thetechniques described herein allow weighting and ordering of policies inthe policy listing even before (or without) the user entering anyexplicit query terms into the text entry field 111. For example, asshown in FIG. 1 , policies for XXService are ranked at the top of thelist based on the context information 126, such as by using theweighting and ordering techniques described above. In some examples,however, the weighting techniques described herein may be used incombination with filtering techniques, such as filtering based on queryterm matches. For example, referring now to FIG. 6 , an example is shownin which a user types the search terms “read” and “only” into text entryfield 111. In response to these query terms, the search results may befiltered to remove all policies that do not include at least one ofthese terms. As shown in FIG. 6 , all of the policies listed in displayarea 112 now include the terms “ReadOnly”. This is in contrast to FIG. 1, in which the display area 112 included several policies that did notinclude the terms “ReadOnly” (e.g., XXServiceFullAccess, XXServiceWrite,etc.). It is noted, however, that, although the policies listed in FIG.6 are filtered such that they all include the terms “ReadOnly”, thepolicies are still nevertheless weighted and ordered using thetechniques described herein. For example, as shown in FIG. 6 , a policyassociated with XXService (i.e., XXService ReadOnly) is still the toplisted policy. This is because policies associated with XXService aredetermined to have the highest relevance to the search based on contextinformation 126.

In the example of FIG. 6 , filtering components 122 are employed tofilter the available policies 121 based on query terms. Specifically,the filtering components 122 filter-out policies that do not include thequery terms “read” or “only”. The policy names that do not match thequery terms “read” or “only” are filtered-out into dropped policies 123.The dropped policies 123 are not weighted and are not displayed indisplay area 112 of FIG. 6 . By contrast, the policy names that do matchthe query terms “read” or “only” are retained in filtered policies 124.The weighting component 125 then performs the weighting and orderingtechniques described herein on the filtered policies 124, and theseresults are shown in display area 112 of FIG. 6 .

In some examples, in addition to being used for filtering purposes, thequery terms entered into text entry field 111 may also be consideredpart of the context information 126 and may be used for policy weightingand ordering. For example, weighting components 125 may be configured toassign higher weights to certain query terms than to other query terms.In some cases, higher weights may be assigned to query terms thatindicate more specific services or resources, while lower weights may beassigned to query terms that correspond to more general entities. As aspecific example, computing services vendor 149 of FIG. 1 may operate anumber of computing services. In some cases, higher weights may be givento query terms that correlate to a specific service, while lower weightsmay be given to query terms that correlate to only the name of thecomputing services vendor 149 itself. As shown in FIGS. 1 and 6 , queryterms 206 are included in context information 126. This indicates thatthe query terms 206 may be considered for weighting and orderingpurposes. Additionally, in some examples, even policy names that do notmatch to an entered query term may not be filtered out—but may insteadbe assigned a lower weight than other policy names that do match anentered query term. For example, in some cases, policy names that do notmatch to an entered query term may be positioned at the end or bottom ofa scrollable list.

In some examples, the calculation of weights for different policies maybe performed based at least in part on a modified version of a rankingfunction, such as Okapi Best Matching (BM) 25, a Jaccard index, oranother ranking function. For example, while these and other rankingfunctions may sometimes be employed to find relevance of a document toquery terms, a modified version of the ranking functions may be employedto find relevance of a policy to query terms. Additionally, in someexamples, in addition or as an alternative to an explicit queryincluding search terms manually entered by the user (e.g., via textentry field 111 of FIGS. 1 and 6 ), a virtual query may be created basedon context information not explicitly entered by the user as a searchterm, such as identity information, existing attached policyinformation, related identities (e.g., other identities within the sameaccount), usage history, and interface browsing history. This virtualquery may then be run through one or more of the modified rankingfunctions described above. In yet another example, both virtual queryterms (e.g., created based on context information not explicitly enteredby the user as a search term) and explicit query terms (e.g., manuallyentered by the user) may be run through the modified ranking functionand may be potentially assigned different weights, such as based onwhich type of information is considered more indicative of the user'ssearch intent.

Thus, the techniques described above may assist a user in findingavailable policies that are contextually relevant. In some cases,however, there may not be any existing available policies that match auser's priorities. In these examples, the user may need to create a newpolicy that matches the user's priorities. In some conventionaltechniques, a user may create a new policy by manually selectingfeatures of the new policy, such as a service, actions (e.g., fillaccess, read, write, list, etc.), resources, conditions, and the like.However, one problem with these conventional techniques is that theremay be limited association between a user's policy search activities anda user's subsequent policy creation activities. For example, consider ascenario in which a user searches for a policy, such as by enteringmultiple different search query terms. Now suppose that the policy forwhich the user searches does not yet exist, and the user is thereforeunable to locate the policy during the search. In some cases, afterperforming an unsuccessful search to attempt to locate the policy, theuser may then navigate to a new policy creation interface and attempt tocreate the new policy. In some conventional techniques, however, theuser may be required to start from scratch when creating the new policy,such as by manually entering all the features of the new policy into theinterface. This may be frustrating to the user, for example because theuser has already invested time and effort in performing the search andmay now be forced to repeat the entry of certain information in order tocreate the new policy.

In order to alleviate these and other problems, the techniques describedherein may provide a policy creation interface that uses contextinformation from the user's search in order to infer and pre-populateone or more suggested features of the new policy within the interface.Referring now to FIG. 7 , an example of a policy creation interface 800with inferred feature suggestions will now be described in detail. Asshown in FIG. 7 , policy creation interface 800 includes servicessection 810, actions section 820, resources section 830 and conditionssection 840. Services section 810 allows selection of services for thenew policy. Actions section 820 allows selection of actions for the newpolicy. Resources section 830 allows selection of resources for the newpolicy. Conditions section 840 allows selection of conditions for thenew policy.

In the example of FIG. 7 , services section 810, actions section 820,resources sections 830, and conditions section 840 include suggestionsmade by the software that are inferred based on a context of a priorpolicy search. Specifically, services section 810 includes suggestedservice 811 (WWService), which is inferred by the software based on thecontext of the prior policy search and pre-populated into the policycreation interface 800 by the software without being manually entered bythe user into the policy creation interface 800. In some examples, ifthe user wishes to change the suggested service 811 to a differentservice, then the user may select edit button 812. Additionally, actionssection 820 includes suggested action 821 (Read Only), which is inferredby the software based on the context of the prior policy search andpre-populated into the policy creation interface 800 by the softwarewithout being manually entered by the user into the policy creationinterface 800. In some examples, if the user wishes to change thesuggested action 821 to a different action, then the user may selectedit button 822. Additionally, resources section 830 includes suggestedresource 831 (MyBucketBBB), which is inferred by the software based onthe context of the prior policy search and pre-populated into the policycreation interface 800 by the software without being manually entered bythe user into the policy creation interface 800. In some examples, ifthe user wishes to change the suggested resource 831 to a differentresource, then the user may select edit button 832. Furthermore,conditions section 840 includes suggested condition 841 (ConditionCCC),which is inferred by the software based on the context of the priorpolicy search and pre-populated into the policy creation interface 800by the software without being manually entered by the user into thepolicy creation interface 800. In some examples, if the user wishes todelete and/or change the suggested condition 841 to a differentcondition, then the user may select edit button 842.

In some examples, after performing a policy search using policy searchpage 100 of FIGS. 1 and 6 , the user may navigate to the policy creationinterface 800 by selecting create policy button 114 of FIGS. 1 and 6 .Selection of the create policy button 114 may cause the policy creationinterface 800 to be pre-populated with suggested information that isinferred from the prior search, such as suggested service 811 andsuggested action 821. The suggested service 811 and the suggested action821 may be selected by the software based on any, or all, of the contextinformation 126 described above, including identity information 201,existing attached policy information 202, related identities 203, usagehistory 204, interface browsing history 205, and query terms 206. Forexample, consider a scenario in which a user attempts to search for apolicy for WWService, with a ReadOnly action, for the resourceMyBucketBBB, with ConditionCCC. Now suppose that a policy with thesefeatures does not yet exist. In this example, the user may enter searchterms such as “WWSerivce” and “read only” and “MyBucketBBB” and“ConditionCCC” into text entry field 111 of FIGS. 1 and 6 . However, thepolicy that the user is searching for will not be provided in the listof policies in display area 112 if it does not yet exist. In this case,once the user sees that the policy that he or she is searching for hasnot been returned as a search result, the user may select the createpolicy button 114 to navigate to policy creation interface 800. In thepolicy creation interface 800, the search query terms previously enteredby the user may be employed by the software to select WWService as thesuggested service 811, to select Read Only as the suggested action 821,to select MyBucketBBB as the suggested resource 831, and to selectConditionCCC as the selected condition 841.

In some examples, one or more query analysis components may be trainedto analyze query terms and match the query terms to features of apolicy, such as a service, an action, a resource, and/or a condition.For example, in some cases, a query analysis component may be providedwith (or otherwise determine) a list of services operated by computingservice vendor 149, and the query analysis component may attempt tomatch search terms entered by the user to one or more of these services.When a query term matches a service name, the query analysis componentsmay then suggest this service as a suggested service 811 in the policycreation interface 800. The query analysis components may also beprovided with (or otherwise determine) a list of actions, and the queryanalysis component may attempt to match search terms entered by the userto one or more of these actions. When a query term matches an actionname, the query analysis components may then suggest this action as asuggested action 821 in the policy creation interface 800. The queryanalysis components may also be provided with (or otherwise determine) alist of common terms for resources (e.g., bucket, table, etc.), and thequery analysis component may attempt to match search terms entered bythe user to one or more of these common resource terms. When a queryterm matches a common resource term, the query analysis components maythen suggest this query term as a suggested resource 831 in the policycreation interface 800. The query analysis components may also beprovided with (or otherwise determine) a list of common condition terms,and the query analysis component may attempt to match search termsentered by the user to one or more of these common condition terms. Whena query term matches a common condition term, the query analysiscomponents may then suggest this query term as a suggested condition 841in the policy creation interface 800.

In some examples, policy creation interface 800 may be employed toperform a copy and modify technique. In these examples, the suggestionsthat are pre-populated into policy creation interface 800 may correspondto features of a pre-existing policy, such as a policy that is a toplisted search result from the policy search page 100. The copy andmodify technique may be advantageous for scenarios when there is anexisting policy that matches some (but not all) of the criteria that theuser desires. In yet other examples, a hybrid technique may be employed,such as when some suggested policy features are extracted from analready existing policy, while other suggested policy features may bedetermined based on query terms or other context information. Thus, thesoftware may select suggested features of the policy creation interface800 based on one or more types of context information 126 including theexample weighting techniques of FIGS. 2-5 and other weighting techniquesdescribed above.

FIG. 8 is a flowchart illustrating an example weighted policy searchingprocess that may be used in accordance with the present disclosure. Theprocess of FIG. 8 is initiated at operation 910, at which an indicationto perform a permissions policy search is received by an interface(e.g., web console interface) of an identity management service. In someexamples, the indication may include a request from a user to navigateto a policy search page, such as policy search page 100 of FIGS. 1 and 6. Additionally, in some examples, prior to navigating to the policysearch page, a user may select a first identity for which to perform thepermission policy search, such as to find a first permissions policy toattach to the first identity.

At operation 912, a context associated with the permissions policysearch is determined. For example, the context may be determined basedon context information, which may include identity information, existingattached policy information, related identities, usage history,interface browsing history, query terms, and other information. Forexample, the identity information may include identity information(e.g., identity name, identity age, etc.) for the first identity forwhich the permissions policy search is being performed. The existingattached policy information may include information about existingattached policies that have already been attached to the first identityand/or to other identities that are related to the first identity. Therelated identities may include information about identities that arerelated to the first identity, such as other identities within a samecustomer account as the first identity. Usage history may include usagehistory for the first identity and/or related identities. Interfacebrowsing history may include a user's browsing history within theidentity management service interface (e.g., web console). Query termsmay include one or more query search terms entered by a user.

At operation 914, a plurality of weights for a plurality of permissionspolicies are calculated based on the context. In some examples, thecalculation may include determining that the context indicates a firstservice. The calculation may also include determining one or more firstpermissions policies of the plurality of permissions policies that areassociated with the first service. The calculation may also includeassigning a higher weight to the one or more first permissions policiesthan to other permissions policies of the plurality of permissionspolicies. In some cases, a corresponding respective weight may becalculated and assigned to each entity of the plurality of entities. Insome examples, the calculation of weights may be performed based atleast in part on a modified version of a ranking function, such as OkapiBest Matching (BM) 25, a Jaccard index, or another ranking function. Forexample, while these and other ranking functions may sometimes beemployed to find relevance of a document to query terms, a modifiedversion of the ranking functions may be employed to find relevance of apolicy to query terms. Additionally, in some examples, in addition or asan alternative to an explicit query including search terms manuallyentered by the user (e.g., via text entry field 111 of FIGS. 1 and 6 ),a virtual query may be created based on context information notexplicitly entered by the user as a search term, such as identityinformation, existing attached policy information, related identities(e.g., other identities within the same account), usage history, andinterface browsing history. This virtual query may then be run throughone or more of the modified ranking functions described above. In yetanother example, both virtual query terms (e.g., created based oncontext information not explicitly entered by the user as a search term)and explicit query terms (e.g., manually entered by the user) may be runthrough the modified ranking function and may be potentially assigneddifferent weights, such as based on which type of information isconsidered more indicative of the user's search intent.

In one specific example, the context may include a name of a firstidentity for which the permissions policy search is being performed, andthe plurality of weights may be calculated based at least in part on thename. Additionally, in one specific example, the context may include ormore existing permissions policies that are attached to the firstidentity for which the permissions policy search is being performed, andthe plurality of weights may be calculated based at least in part on theone or more existing permissions policies. Furthermore, in one specificexample, the context may include one or more existing permissionspolicies that are attached to a second identity that is related to thefirst identity, and the plurality of weights may be calculated based atleast in part on the one or more existing permissions policies. In yetanother specific example, the context may include a resource usagehistory of the first identity, and the plurality of weights may becalculated based at least in part on the resource usage history. In yetanother specific example, the context may include an interface browsinghistory, and the plurality of weights may be calculated based at leastin part on the interface browsing history.

At operation 916, an order for display of the plurality of permissionspolicies may be determined based on the plurality of weights. A policy'sposition in an ordered list may be determined based on its respectiveweight (e.g., rank), for example such that higher weighted policies aredisplayed with a higher priority (e.g., higher up in the list), whilelower weighted policies are displayed with a lower priority (e.g.,further down in the list). For example, a highest weighted policy may beassigned the highest priority in an order, such as being positioned atthe top of an ordered list. A second-highest weighted policy may beassigned a second-highest priority in an order, such as being positionedsecond from the top of the ordered list. This ordering process maycontinue until the lowest weighted policy is assigned a lowest priorityin the order, such as being positioned at the bottom of the orderedlist. At operation 918, the plurality of permissions policies arepresented (e.g., displayed), in a display area within the interface, inthe order that is based on the plurality of weights. For example, asshown in FIGS. 1 and 6 , the weighted permissions policies are displayedin display area 112 of policy search page 100, such as in a scrollablelist of permissions policies. The display area 112 includes checkboxes115 to the left of each permissions policy that may be selected by auser in order to select the corresponding respective permissions policy.

At operation 920, it is determined whether the policy for which the useris searching currently exists. For example, if the policy is included inthe search results, then the user may determine that the policy exists.By contrast, if the user is unable to find the policy within the searchresults, then the user may determine that the policy does not yet exist.If the policy exists, then, at operation 922, the interface receives aselection of a first permissions policy from the plurality ofpermissions policies. For example, the user may select the firstpermission policy by checking the respective checkbox to the left of thefirst permissions policy. The user may then click select policy button113 to cause all policies that have been selected by the user within thedisplay area 112 (e.g., all policies whose checkboxes are selected) tobe selected. At operation 924, the first permissions policy is attachedto a first identity based at least in part on the selection of the firstpermissions policy. For example, in some cases, prior to performing thepermissions policy search, the user may select the first identity towhich the selected policy will be attached. In this example, clicking ofselect policy button 113 may cause the software to attach each selectedpolicy to the first identity. In other examples, the user may clickselect policy button and may then subsequently select the first identityto which the selected policy will be attached.

By contrast, if the policy for which the user is searching does notcurrently exist, then, at operation 926, one or more suggestions forcreation of a new permissions policy are provided based at least in parton the context. In some examples, the one or more suggestions mayinclude suggested features, such as a suggested service, a suggestedaction, a suggested resource and/or a suggested condition. For example,in some cases, if the user cannot find the policy for which he or she issearching, the user may click create policy button 114 of FIGS. 1 and 6, which may cause policy creation interface 800 of FIG. 7 to bedisplayed. The policy creation interface may include a suggestedservice, a suggested action, a suggested resource, a suggested conditionand/or other suggested features for the new policy that is beingcreated. These suggested features may be inferred by the software basedon the context information and the weighting techniques described above.

An example system for transmitting and providing data will now bedescribed in detail. In particular, FIG. 9 illustrates an examplecomputing environment in which the embodiments described herein may beimplemented. FIG. 9 is a diagram schematically illustrating an exampleof a data center 85 that can provide computing resources to users 70 aand 70 b (which may be referred herein singularly as user 70 or in theplural as users 70) via user computers 72 a and 72 b (which may bereferred herein singularly as computer 72 or in the plural as computers72) via a communications network 73. Data center 85 may be configured toprovide computing resources for executing applications on a permanent oran as-needed basis. The computing resources provided by data center 85may include various types of resources, such as gateway resources, loadbalancing resources, routing resources, networking resources, computingresources, volatile and non-volatile memory resources, content deliveryresources, data processing resources, data storage resources, datacommunication resources and the like. Each type of computing resourcemay be available in a number of specific configurations. For example,data processing resources may be available as virtual machine instancesthat may be configured to provide various web services. In addition,combinations of resources may be made available via a network and may beconfigured as one or more web services. The instances may be configuredto execute applications, including web services, such as applicationservices, media services, database services, processing services,gateway services, storage services, routing services, security services,encryption services, load balancing services, application services andthe like. These services may be configurable with set or customapplications and may be configurable in size, execution, cost, latency,type, duration, accessibility and in any other dimension. These webservices may be configured as available infrastructure for one or moreclients and can include one or more applications configured as aplatform or as software for one or more clients. These web services maybe made available via one or more communications protocols. Thesecommunications protocols may include, for example, hypertext transferprotocol (HTTP) or non-HTTP protocols. These communications protocolsmay also include, for example, more reliable transport layer protocols,such as transmission control protocol (TCP), and less reliable transportlayer protocols, such as user datagram protocol (UDP). Data storageresources may include file storage devices, block storage devices andthe like.

Each type or configuration of computing resource may be available indifferent sizes, such as large resources—consisting of many processors,large amounts of memory and/or large storage capacity—and smallresources—consisting of fewer processors, smaller amounts of memoryand/or smaller storage capacity. Customers may choose to allocate anumber of small processing resources as web servers and/or one largeprocessing resource as a database server, for example.

Data center 85 may include servers 76 a and 76 b (which may be referredherein singularly as server 76 or in the plural as servers 76) thatprovide computing resources. These resources may be available as baremetal resources or as virtual machine instances 78 a-b (which may bereferred herein singularly as virtual machine instance 78 or in theplural as virtual machine instances 78). In this example, the resourcesalso include contextual weighting virtual machines (CSVM's) 79 a-b,which are virtual machines that are configured to execute any, or all,of the contextual policy weighting techniques described herein, such asto assist in ordering of policies for permissions search results asdescribed above.

The availability of virtualization technologies for computing hardwarehas afforded benefits for providing large scale computing resources forcustomers and allowing computing resources to be efficiently andsecurely shared between multiple customers. For example, virtualizationtechnologies may allow a physical computing device to be shared amongmultiple users by providing each user with one or more virtual machineinstances hosted by the physical computing device. A virtual machineinstance may be a software emulation of a particular physical computingsystem that acts as a distinct logical computing system. Such a virtualmachine instance provides isolation among multiple operating systemssharing a given physical computing resource. Furthermore, somevirtualization technologies may provide virtual resources that span oneor more physical resources, such as a single virtual machine instancewith multiple virtual processors that span multiple distinct physicalcomputing systems.

Referring to FIG. 9 , communications network 73 may, for example, be apublicly accessible network of linked networks and possibly operated byvarious distinct parties, such as the Internet. In other embodiments,communications network 73 may be a private network, such as a corporateor university network that is wholly or partially inaccessible tonon-privileged users. In still other embodiments, communications network73 may include one or more private networks with access to and/or fromthe Internet.

Communication network 73 may provide access to computers 72. Usercomputers 72 may be computers utilized by users 70 or other customers ofdata center 85. For instance, user computer 72 a or 72 b may be aserver, a desktop or laptop personal computer, a tablet computer, awireless telephone, a personal digital assistant (PDA), an e-bookreader, a game console, a set-top box or any other computing devicecapable of accessing data center 85. User computer 72 a or 72 b mayconnect directly to the Internet (e.g., via a cable modem or a DigitalSubscriber Line (DSL)). Although only two user computers 72 a and 72 bare depicted, it should be appreciated that there may be multiple usercomputers.

User computers 72 may also be utilized to configure aspects of thecomputing resources provided by data center 85. In this regard, datacenter 85 might provide a gateway or web interface through which aspectsof its operation may be configured through the use of a web browserapplication program executing on user computer 72. Alternately, astand-alone application program executing on user computer 72 mightaccess an application programming interface (API) exposed by data center85 for performing the configuration operations. Other mechanisms forconfiguring the operation of various web services available at datacenter 85 might also be utilized.

Servers 76 shown in FIG. 9 may be servers configured appropriately forproviding the computing resources described above and may providecomputing resources for executing one or more web services and/orapplications. In one embodiment, the computing resources may be virtualmachine instances 78. In the example of virtual machine instances, eachof the servers 76 may be configured to execute an instance manager 80 aor 80 b (which may be referred herein singularly as instance manager 80or in the plural as instance managers 80) capable of executing thevirtual machine instances 78. The instance managers 80 may be a virtualmachine monitor (VMM) or another type of program configured to enablethe execution of virtual machine instances 78 on server 76, for example.As discussed above, each of the virtual machine instances 78 may beconfigured to execute all or a portion of an application.

It should be appreciated that although the embodiments disclosed abovediscuss the context of virtual machine instances, other types ofimplementations can be utilized with the concepts and technologiesdisclosed herein. For example, the embodiments disclosed herein mightalso be utilized with computing systems that do not utilize virtualmachine instances.

In the example data center 85 shown in FIG. 9 , a router 71 may beutilized to interconnect the servers 76 a and 76 b. Router 71 may alsobe connected to gateway 74, which is connected to communications network73. Router 71 may be connected to one or more load balancers, and aloneor in combination may manage communications within networks in datacenter 85, for example, by forwarding packets or other datacommunications as appropriate based on characteristics of suchcommunications (e.g., header information including source and/ordestination addresses, protocol identifiers, size, processingrequirements, etc.) and/or the characteristics of the private network(e.g., routes based on network topology, etc.). It will be appreciatedthat, for the sake of simplicity, various aspects of the computingsystems and other devices of this example are illustrated withoutshowing certain conventional details. Additional computing systems andother devices may be interconnected in other embodiments and may beinterconnected in different ways.

In the example data center 85 shown in FIG. 9 , a server manager 75 isalso employed to at least in part direct various communications to, fromand/or between servers 76 a and 76 b. While FIG. 9 depicts router 71positioned between gateway 74 and server manager 75, this is merely anexemplary configuration. In some cases, for example, server manager 75may be positioned between gateway 74 and router 71. Server manager 75may, in some cases, examine portions of incoming communications fromuser computers 72 to determine one or more appropriate servers 76 toreceive and/or process the incoming communications. Server manager 75may determine appropriate servers to receive and/or process the incomingcommunications based on factors such as an identity, location or otherattributes associated with user computers 72, a nature of a task withwhich the communications are associated, a priority of a task with whichthe communications are associated, a duration of a task with which thecommunications are associated, a size and/or estimated resource usage ofa task with which the communications are associated and many otherfactors. Server manager 75 may, for example, collect or otherwise haveaccess to state information and other information associated withvarious tasks in order to, for example, assist in managingcommunications and other operations associated with such tasks.

It should be appreciated that the network topology illustrated in FIG. 9has been greatly simplified and that many more networks and networkingdevices may be utilized to interconnect the various computing systemsdisclosed herein. These network topologies and devices should beapparent to those skilled in the art.

It should also be appreciated that data center 85 described in FIG. 9 ismerely illustrative and that other implementations might be utilized. Itshould also be appreciated that a server, gateway or other computingdevice may comprise any combination of hardware or software that caninteract and perform the described types of functionality, includingwithout limitation: desktop or other computers, database servers,network storage devices and other network devices, PDAs, tablets,cellphones, wireless phones, pagers, electronic organizers, Internetappliances, television-based systems (e.g., using set top boxes and/orpersonal/digital video recorders) and various other consumer productsthat include appropriate communication capabilities.

In at least some embodiments, a server that implements a portion or allof one or more of the technologies described herein may include acomputer system that includes or is configured to access one or morecomputer-accessible media. FIG. 10 depicts a computer system thatincludes or is configured to access one or more computer-accessiblemedia. In the illustrated embodiment, computing device 15 includes oneor more processors 10 a, 10 b and/or 10 n (which may be referred hereinsingularly as “a processor 10” or in the plural as “the processors 10”)coupled to a system memory 20 via an input/output (I/O) interface 30.Computing device 15 further includes a network interface 40 coupled toI/O interface 30.

In various embodiments, computing device 15 may be a uniprocessor systemincluding one processor 10 or a multiprocessor system including severalprocessors 10 (e.g., two, four, eight or another suitable number).Processors 10 may be any suitable processors capable of executinginstructions. For example, in various embodiments, processors 10 may beembedded processors implementing any of a variety of instruction setarchitectures (ISAs), such as the x86, PowerPC, SPARC or MIPS ISAs orany other suitable ISA. In multiprocessor systems, each of processors 10may commonly, but not necessarily, implement the same ISA.

System memory 20 may be configured to store instructions and dataaccessible by processor(s) 10. In various embodiments, system memory 20may be implemented using any suitable memory technology, such as staticrandom access memory (SRAM), synchronous dynamic RAM (SDRAM),nonvolatile/Flash®-type memory or any other type of memory. In theillustrated embodiment, program instructions and data implementing oneor more desired functions, such as those methods, techniques and datadescribed above, are shown stored within system memory 20 as code 25 anddata 26. Additionally, in this example, system memory 20 includescontextual weighting instructions 27, which are instructions forexecuting any, or all, of the contextual policy weighting techniquesdescribed herein, such as to assist in ordering of policies forpermissions search results as described above.

In one embodiment, I/O interface 30 may be configured to coordinate I/Otraffic between processor 10, system memory 20 and any peripherals inthe device, including network interface 40 or other peripheralinterfaces. In some embodiments, I/O interface 30 may perform anynecessary protocol, timing or other data transformations to convert datasignals from one component (e.g., system memory 20) into a formatsuitable for use by another component (e.g., processor 10). In someembodiments, I/O interface 30 may include support for devices attachedthrough various types of peripheral buses, such as a variant of thePeripheral Component Interconnect (PCI) bus standard or the UniversalSerial Bus (USB) standard, for example. In some embodiments, thefunction of I/O interface 30 may be split into two or more separatecomponents, such as a north bridge and a south bridge, for example.Also, in some embodiments some or all of the functionality of I/Ointerface 30, such as an interface to system memory 20, may beincorporated directly into processor 10.

Network interface 40 may be configured to allow data to be exchangedbetween computing device 15 and other device or devices 60 attached to anetwork or networks 50, such as other computer systems or devices, forexample. In various embodiments, network interface 40 may supportcommunication via any suitable wired or wireless general data networks,such as types of Ethernet networks, for example. Additionally, networkinterface 40 may support communication via telecommunications/telephonynetworks, such as analog voice networks or digital fiber communicationsnetworks, via storage area networks such as Fibre Channel SANs (storagearea networks) or via any other suitable type of network and/orprotocol.

In some embodiments, system memory 20 may be one embodiment of acomputer-accessible medium configured to store program instructions anddata as described above for implementing embodiments of thecorresponding methods and apparatus. However, in other embodiments,program instructions and/or data may be received, sent or stored upondifferent types of computer-accessible media. Generally speaking, acomputer-accessible medium may include non-transitory storage media ormemory media, such as magnetic or optical media—e.g., disk or DVD/CDcoupled to computing device 15 via I/O interface 30. A non-transitorycomputer-accessible storage medium may also include any volatile ornon-volatile media, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM,etc.), ROM (read only memory) etc., that may be included in someembodiments of computing device 15 as system memory 20 or another typeof memory. Further, a computer-accessible medium may includetransmission media or signals such as electrical, electromagnetic ordigital signals conveyed via a communication medium, such as a networkand/or a wireless link, such as those that may be implemented vianetwork interface 40.

A network set up by an entity, such as a company or a public sectororganization, to provide one or more web services (such as various typesof cloud-based computing or storage) accessible via the Internet and/orother networks to a distributed set of clients may be termed a providernetwork. Such a provider network may include numerous data centershosting various resource pools, such as collections of physical and/orvirtualized computer servers, storage devices, networking equipment andthe like, needed to implement and distribute the infrastructure and webservices offered by the provider network. The resources may in someembodiments be offered to clients in various units related to the webservice, such as an amount of storage capacity for storage, processingcapability for processing, as instances, as sets of related services andthe like. A virtual computing instance may, for example, comprise one ormore servers with a specified computational capacity (which may bespecified by indicating the type and number of CPUs, the main memorysize and so on) and a specified software stack (e.g., a particularversion of an operating system, which may in turn run on top of ahypervisor).

A compute node, which may be referred to also as a computing node, maybe implemented on a wide variety of computing environments, such ascommodity-hardware computers, virtual machines, web services, computingclusters and computing appliances. Any of these computing devices orenvironments may, for convenience, be described as compute nodes.

A number of different types of computing devices may be used singly orin combination to implement the resources of the provider network indifferent embodiments, for example computer servers, storage devices,network devices and the like. In some embodiments a client or user maybe provided direct access to a resource instance, e.g., by giving a useran administrator login and password. In other embodiments the providernetwork operator may allow clients to specify execution requirements forspecified client applications and schedule execution of the applicationson behalf of the client on execution platforms (such as applicationserver instances, Java′ virtual machines (JVMs), general-purpose orspecial-purpose operating systems, platforms that support variousinterpreted or compiled programming languages such as Ruby, Perl,Python, C, C++ and the like or high-performance computing platforms)suitable for the applications, without, for example, requiring theclient to access an instance or an execution platform directly. A givenexecution platform may utilize one or more resource instances in someimplementations; in other implementations, multiple execution platformsmay be mapped to a single resource instance.

In many environments, operators of provider networks that implementdifferent types of virtualized computing, storage and/or othernetwork-accessible functionality may allow customers to reserve orpurchase access to resources in various resource acquisition modes. Thecomputing resource provider may provide facilities for customers toselect and launch the desired computing resources, deploy applicationcomponents to the computing resources and maintain an applicationexecuting in the environment. In addition, the computing resourceprovider may provide further facilities for the customer to quickly andeasily scale up or scale down the numbers and types of resourcesallocated to the application, either manually or through automaticscaling, as demand for or capacity requirements of the applicationchange. The computing resources provided by the computing resourceprovider may be made available in discrete units, which may be referredto as instances. An instance may represent a physical server hardwareplatform, a virtual machine instance executing on a server or somecombination of the two. Various types and configurations of instancesmay be made available, including different sizes of resources executingdifferent operating systems (OS) and/or hypervisors, and with variousinstalled software applications, runtimes and the like. Instances mayfurther be available in specific availability zones, representing alogical region, a fault tolerant region, a data center or othergeographic location of the underlying computing hardware, for example.Instances may be copied within an availability zone or acrossavailability zones to improve the redundancy of the instance, andinstances may be migrated within a particular availability zone oracross availability zones. As one example, the latency for clientcommunications with a particular server in an availability zone may beless than the latency for client communications with a different server.As such, an instance may be migrated from the higher latency server tothe lower latency server to improve the overall client experience.

In some embodiments the provider network may be organized into aplurality of geographical regions, and each region may include one ormore availability zones. An availability zone (which may also bereferred to as an availability container) in turn may comprise one ormore distinct locations or data centers, configured in such a way thatthe resources in a given availability zone may be isolated or insulatedfrom failures in other availability zones. That is, a failure in oneavailability zone may not be expected to result in a failure in anyother availability zone. Thus, the availability profile of a resourceinstance is intended to be independent of the availability profile of aresource instance in a different availability zone. Clients may be ableto protect their applications from failures at a single location bylaunching multiple application instances in respective availabilityzones. At the same time, in some implementations inexpensive and lowlatency network connectivity may be provided between resource instancesthat reside within the same geographical region (and networktransmissions between resources of the same availability zone may beeven faster).

As set forth above, content may be provided by a content provider to oneor more clients. The term content, as used herein, refers to anypresentable information, and the term content item, as used herein,refers to any collection of any such presentable information. A contentprovider may, for example, provide one or more content providingservices for providing content to clients. The content providingservices may reside on one or more servers. The content providingservices may be scalable to meet the demands of one or more customersand may increase or decrease in capability based on the number and typeof incoming client requests. Portions of content providing services mayalso be migrated to be placed in positions of reduced latency withrequesting clients. For example, the content provider may determine an“edge” of a system or network associated with content providing servicesthat is physically and/or logically closest to a particular client. Thecontent provider may then, for example, “spin-up,” migrate resources orotherwise employ components associated with the determined edge forinteracting with the particular client. Such an edge determinationprocess may, in some cases, provide an efficient technique foridentifying and employing components that are well suited to interactwith a particular client, and may, in some embodiments, reduce thelatency for communications between a content provider and one or moreclients.

In addition, certain methods or process blocks may be omitted in someimplementations. The methods and processes described herein are also notlimited to any particular sequence, and the blocks or states relatingthereto can be performed in other sequences that are appropriate. Forexample, described blocks or states may be performed in an order otherthan that specifically disclosed, or multiple blocks or states may becombined in a single block or state. The example blocks or states may beperformed in serial, in parallel or in some other manner. Blocks orstates may be added to or removed from the disclosed exampleembodiments.

It will also be appreciated that various items are illustrated as beingstored in memory or on storage while being used, and that these items orportions thereof may be transferred between memory and other storagedevices for purposes of memory management and data integrity.Alternatively, in other embodiments some or all of the software modulesand/or systems may execute in memory on another device and communicatewith the illustrated computing systems via inter-computer communication.Furthermore, in some embodiments, some or all of the systems and/ormodules may be implemented or provided in other ways, such as at leastpartially in firmware and/or hardware, including, but not limited to,one or more application-specific integrated circuits (ASICs), standardintegrated circuits, controllers (e.g., by executing appropriateinstructions, and including microcontrollers and/or embeddedcontrollers), field-programmable gate arrays (FPGAs), complexprogrammable logic devices (CPLDs), etc. Some or all of the modules,systems and data structures may also be stored (e.g., as softwareinstructions or structured data) on a computer-readable medium, such asa hard disk, a memory, a network or a portable media article to be readby an appropriate drive or via an appropriate connection. The systems,modules and data structures may also be transmitted as generated datasignals (e.g., as part of a carrier wave or other analog or digitalpropagated signal) on a variety of computer-readable transmission media,including wireless-based and wired/cable-based media, and may take avariety of forms (e.g., as part of a single or multiplexed analogsignal, or as multiple discrete digital packets or frames). Suchcomputer program products may also take other forms in otherembodiments. Accordingly, the present invention may be practiced withother computer system configurations.

Conditional language used herein, such as, among others, “can,” “could,”“might,” “may,” “e.g.” and the like, unless specifically statedotherwise, or otherwise understood within the context as used, isgenerally intended to convey that certain embodiments include, whileother embodiments do not include, certain features, elements, and/orsteps. Thus, such conditional language is not generally intended toimply that features, elements and/or steps are in any way required forone or more embodiments or that one or more embodiments necessarilyinclude logic for deciding, with or without author input or prompting,whether these features, elements and/or steps are included or are to beperformed in any particular embodiment. The terms “comprising,”“including,” “having” and the like are synonymous and are usedinclusively, in an open-ended fashion, and do not exclude additionalelements, features, acts, operations and so forth. Also, the term “or”is used in its inclusive sense (and not in its exclusive sense) so thatwhen used, for example, to connect a list of elements, the term “or”means one, some or all of the elements in the list.

While certain example embodiments have been described, these embodimentshave been presented by way of example only and are not intended to limitthe scope of the inventions disclosed herein. Thus, nothing in theforegoing description is intended to imply that any particular feature,characteristic, step, module or block is necessary or indispensable.Indeed, the novel methods and systems described herein may be embodiedin a variety of other forms; furthermore, various omissions,substitutions and changes in the form of the methods and systemsdescribed herein may be made without departing from the spirit of theinventions disclosed herein. The accompanying claims and theirequivalents are intended to cover such forms or modifications as wouldfall within the scope and spirit of certain of the inventions disclosedherein.

What is claimed is:
 1. A computing system comprising: one or moreprocessors; and one or more memories having stored therein instructionsthat, upon execution by one or more computer processors, cause the oneor more computer processors to perform operations comprising: receiving,by an interface of an identity management service, an indication toperform a permissions policy search; determining a context associatedwith the permissions policy search; calculating, based on the context, aplurality of weights for a plurality of permissions policies;determining, based on the plurality of weights, an order for display ofthe plurality of permissions policies; presenting, in a list within theinterface, the plurality of permissions policies in the order that isbased on the plurality of weights; receiving, by the interface, aselection of a first permissions policy from the plurality ofpermissions policies; and attaching the first permissions policy to afirst identity based at least in part on the selection of the firstpermissions policy.
 2. The computing system of claim 1, wherein thecontext comprises a name of the first identity, and wherein theplurality of weights are calculated based at least in part on the name.3. The computing system of claim 1, wherein the context comprises one ormore existing permissions policies that are attached to the firstidentity, and wherein the plurality of weights are calculated based atleast in part on the one or more existing permissions policies.
 4. Thecomputing system of claim 1, wherein the context comprises one or moreexisting permissions policies that are attached to a second identitythat is related to the first identity, and wherein the plurality ofweights are calculated based at least in part on the one or moreexisting permissions policies.
 5. A computer-implemented methodcomprising: receiving, by an interface of an identity managementservice, an indication to perform a permissions policy search;determining a context associated with the permissions policy search;calculating, based on the context, a plurality of weights for aplurality of permissions policies; determining, based on the pluralityof weights, an order for display of the plurality of permissionspolicies; and presenting, in a display area within the interface, theplurality of permissions policies in the order that is based on theplurality of weights.
 6. The computer-implemented method of claim 5,further comprising: receiving, by the interface, a selection of a firstpermissions policy from the plurality of permissions policies; andattaching the first permissions policy to a first identity based atleast in part on the selection of the first permissions policy.
 7. Thecomputer-implemented method of claim 5, wherein the context comprises aname of a first identity for which the permissions policy search isbeing performed, and wherein the plurality of weights are calculatedbased at least in part on the name.
 8. The computer-implemented methodof claim 5, wherein the context comprises one or more existingpermissions policies that are attached to a first identity for which thepermissions policy search is being performed, and wherein the pluralityof weights are calculated based at least in part on the one or moreexisting permissions policies.
 9. The computer-implemented method ofclaim 5, wherein the context comprises one or more existing permissionspolicies that are attached to a second identity that is related to afirst identity for which the permissions policy search is beingperformed, and wherein the plurality of weights are calculated based atleast in part on the one or more existing permissions policies.
 10. Thecomputer-implemented method of claim 5, wherein the context comprises aresource usage history of a first identity for which the permissionspolicy search is being performed, and wherein the plurality of weightsare calculated based at least in part on the resource usage history. 11.The computer-implemented method of claim 5, wherein the contextcomprises an interface browsing history, and wherein the plurality ofweights are calculated based at least in part on the interface browsinghistory.
 12. The computer-implemented method of claim 5, wherein theassigning the plurality of weights to the plurality of permissionspolicies comprises: determining that the context indicates a firstservice; determining one or more first permissions policies of theplurality of permissions policies that are associated with the firstservice; and assigning a higher weight to the one or more firstpermissions policies than to other permissions policies of the pluralityof permissions policies.
 13. The computer-implemented method of claim 5,further comprising: providing, based at least in part on the context,one or more suggestions for creation of a new permissions policy,wherein the one or more suggestions comprise at least one of a suggestedservice, a suggested action, a suggested resource, or a suggestedcondition.
 14. One or more non-transitory computer-readable storagemedia having stored thereon computing instructions that, upon executionby one or computing devices, cause the one or more computing devices toperform operations comprising: receiving, by an interface, an indicationto perform a permissions policy search; determining a context associatedwith the permissions policy search; calculating, based on the context, aplurality of weights for a plurality of permissions policies;determining, based on the plurality of weights, an order for display ofthe plurality of permissions policies; presenting, in a display areawithin the interface, the plurality of permissions policies in the orderthat is based on the plurality of weights; receiving, by the interface,a selection of a first permissions policy from the plurality ofpermissions policies; and attaching the first permissions policy to afirst identity based at least in part on the selection of the firstpermissions policy.
 15. The one or more non-transitory computer-readablestorage media of claim 14, wherein the context comprises a name of thefirst identity, and wherein the plurality of weights are calculatedbased at least in part on the name.
 16. The one or more non-transitorycomputer-readable storage media of claim 14, wherein the contextcomprises one or more existing permissions policies that are attached tothe first identity, and wherein the plurality of weights are calculatedbased at least in part on the one or more existing permissions policies.17. The one or more non-transitory computer-readable storage media ofclaim 14, wherein the context comprises one or more existing permissionspolicies that are attached to a second identity that is related to thefirst identity, and wherein the plurality of weights are calculatedbased at least in part on the one or more existing permissions policies.18. The one or more non-transitory computer-readable storage media ofclaim 14, wherein the context comprises a resource usage history of thefirst identity, and wherein the plurality of weights are calculatedbased at least in part on the resource usage history.
 19. The one ormore non-transitory computer-readable storage media of claim 14, whereinthe context comprises an interface browsing history, and wherein theplurality of weights are calculated based at least in part on theinterface browsing history.
 20. The one or more non-transitorycomputer-readable storage media of claim 14, wherein the assigning theplurality of weights to the plurality of permissions policies comprises:determining that the context indicates a first service; determining oneor more first permissions policies of the plurality of permissionspolicies that are associated with the first service; and assigning ahigher weight to the one or more first permissions policies than toother permissions policies of the plurality of permissions policies.